fix: resolve deploy tx from receipts table for contract creation info#907
Open
fix: resolve deploy tx from receipts table for contract creation info#907
Conversation
The metadata endpoint queried txs WHERE from=addr OR to=addr, but deploy txs have to=NULL — the deployed address only appears in receipts.contract_address. This caused January (and any older) deployments with no post-deploy interactions to show no creation data. Changes: - fetchAddressTxAggregate: add parallel receipts query for contract_address to find the actual deploy tx hash, deployer, and timestamp - metadata route: prefer deploy receipt data over oldest-tx heuristic - address page: gate RPC fallback on missing createdTxHash instead of createdTimestamp so the fallback fires when TIDX returns a timestamp from a post-deploy call but no deploy hash Amp-Thread-ID: https://ampcode.com/threads/T-019de496-ae30-77a9-8292-f1fbb9f7c49e Co-authored-by: Amp <amp@ampcode.com>
Bundle Size Report
Chunk changes (>1KB)
Compared against main branch (baseline from 4/27/2026, 4:02:54 PM) |
Cloudflare Deployments
|
….com/tempoxyz/tempo-apps into centaur/fix-deploy-tx-lookup Amp-Thread-ID: https://ampcode.com/threads/T-019de496-ae30-77a9-8292-f1fbb9f7c49e Co-authored-by: Amp <amp@ampcode.com>
goksu
reviewed
May 5, 2026
| fetchBoundaryByField('to', 'desc'), | ||
| fetchBoundaryByField('from', 'asc'), | ||
| fetchBoundaryByField('to', 'asc'), | ||
| fetchDeployReceipt(), |
Member
There was a problem hiding this comment.
I am increasingly vary of adding "one more separate query" for features like these. Won't block this if creator wants to land it (can't find the Amp thread) but something we need to be more careful about.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the bug where deploy tx/deployer/created date do not appear for older contracts, and preserves the Contract tab even when index aggregate queries fail.
Root cause
There were two separate problems:
fetchAddressTxAggregatequeriedtxs WHERE from = addr OR to = addr, but deploy txs haveto = NULL, so older contracts could miss creation metadata unless their deploy receipt was consulted.accountType: empty, which could hide the Contract tab even wheneth_getCodeshowed the address was a contract.Changes
tempo-queries.ts— add a parallelreceipts WHERE contract_address = address LIMIT 1query insidefetchAddressTxAggregateto fetch the actual deploy tx hash, deployer, and timestamp directly from the indexed receipts table.metadata/$address.ts— prefer the deploy receipt over the oldest-tx heuristic forcreatedTxHash,createdBy, andcreatedTimestamp.address/$address.tsx— gate the RPC binary-search fallback on!createdTxHashinstead of!createdTimestamp, so it still fires when TIDX returns a timestamp from a post-deploy call but no deploy hash.metadata/$address.ts— deriveaccountTypefrometh_getCodeup front and preserve that contract/account classification even if aggregate index queries fail, instead of returningaccountType: empty.Verification
Notes
corepack pnpm check:typesinapps/explorerstill fails on pre-existing unrelated typing issues in the workspace.Status: 400forchainId=31318; this PR prevents that backend failure from hiding the Contract tab, but does not resolve the TIDX-side 400 itself.Companion to #906.